<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: common.hpp Source File</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;1.0.2</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
</div><!-- top -->
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div class="header">
  <div class="headertitle"><div class="title">common.hpp</div></div>
</div><!--header-->
<div class="contents">
<a href="common_8hpp.html">Go to the documentation of this file.</a><div class="fragment"><div class="line"><a id="l00001" name="l00001"></a><span class="lineno">    1</span><span class="comment">/* Flow-IPC: Core</span></div>
<div class="line"><a id="l00002" name="l00002"></a><span class="lineno">    2</span><span class="comment"> * Copyright 2023 Akamai Technologies, Inc.</span></div>
<div class="line"><a id="l00003" name="l00003"></a><span class="lineno">    3</span><span class="comment"> *</span></div>
<div class="line"><a id="l00004" name="l00004"></a><span class="lineno">    4</span><span class="comment"> * Licensed under the Apache License, Version 2.0 (the</span></div>
<div class="line"><a id="l00005" name="l00005"></a><span class="lineno">    5</span><span class="comment"> * &quot;License&quot;); you may not use this file except in</span></div>
<div class="line"><a id="l00006" name="l00006"></a><span class="lineno">    6</span><span class="comment"> * compliance with the License.  You may obtain a copy</span></div>
<div class="line"><a id="l00007" name="l00007"></a><span class="lineno">    7</span><span class="comment"> * of the License at</span></div>
<div class="line"><a id="l00008" name="l00008"></a><span class="lineno">    8</span><span class="comment"> *</span></div>
<div class="line"><a id="l00009" name="l00009"></a><span class="lineno">    9</span><span class="comment"> *   https://www.apache.org/licenses/LICENSE-2.0</span></div>
<div class="line"><a id="l00010" name="l00010"></a><span class="lineno">   10</span><span class="comment"> *</span></div>
<div class="line"><a id="l00011" name="l00011"></a><span class="lineno">   11</span><span class="comment"> * Unless required by applicable law or agreed to in</span></div>
<div class="line"><a id="l00012" name="l00012"></a><span class="lineno">   12</span><span class="comment"> * writing, software distributed under the License is</span></div>
<div class="line"><a id="l00013" name="l00013"></a><span class="lineno">   13</span><span class="comment"> * distributed on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR</span></div>
<div class="line"><a id="l00014" name="l00014"></a><span class="lineno">   14</span><span class="comment"> * CONDITIONS OF ANY KIND, either express or implied.</span></div>
<div class="line"><a id="l00015" name="l00015"></a><span class="lineno">   15</span><span class="comment"> * See the License for the specific language governing</span></div>
<div class="line"><a id="l00016" name="l00016"></a><span class="lineno">   16</span><span class="comment"> * permissions and limitations under the License. */</span></div>
<div class="line"><a id="l00017" name="l00017"></a><span class="lineno">   17</span><span class="comment"></span> </div>
<div class="line"><a id="l00018" name="l00018"></a><span class="lineno">   18</span><span class="comment">/// @file</span></div>
<div class="line"><a id="l00019" name="l00019"></a><span class="lineno">   19</span><span class="comment"></span><span class="preprocessor">#pragma once</span></div>
<div class="line"><a id="l00020" name="l00020"></a><span class="lineno">   20</span> </div>
<div class="line"><a id="l00021" name="l00021"></a><span class="lineno">   21</span><span class="comment">/* @todo More consistent to move this below `#include &quot;ipc/...&quot;`; but flow/common.hpp needs to #undef a couple things</span></div>
<div class="line"><a id="l00022" name="l00022"></a><span class="lineno">   22</span><span class="comment"> * before `#define`ing them (FLOW_LOG_CFG_COMPONENT_ENUM_*) for that to work.  It really should anyway. */</span></div>
<div class="line"><a id="l00023" name="l00023"></a><span class="lineno">   23</span><span class="preprocessor">#include &lt;flow/util/util.hpp&gt;</span></div>
<div class="line"><a id="l00024" name="l00024"></a><span class="lineno">   24</span> </div>
<div class="line"><a id="l00025" name="l00025"></a><span class="lineno">   25</span><span class="preprocessor">#include &quot;<a class="code" href="detail_2common_8hpp.html">ipc/detail/common.hpp</a>&quot;</span></div>
<div class="line"><a id="l00026" name="l00026"></a><span class="lineno">   26</span><span class="preprocessor">#include &lt;boost/interprocess/interprocess_fwd.hpp&gt;</span></div>
<div class="line"><a id="l00027" name="l00027"></a><span class="lineno">   27</span><span class="preprocessor">#include &lt;boost/filesystem.hpp&gt;</span></div>
<div class="line"><a id="l00028" name="l00028"></a><span class="lineno">   28</span> </div>
<div class="line"><a id="l00029" name="l00029"></a><span class="lineno">   29</span><span class="comment">/* We build in C++17 mode ourselves (as of this writing), but linking user shouldn&#39;t care about that so much.</span></div>
<div class="line"><a id="l00030" name="l00030"></a><span class="lineno">   30</span><span class="comment"> * The APIs and header-inlined stuff (templates, constexprs, possibly explicitly-inlined functions [though we avoid</span></div>
<div class="line"><a id="l00031" name="l00031"></a><span class="lineno">   31</span><span class="comment"> * those]), however, also requires C++17 or newer; and that applies to the linking user&#39;s `#include`ing .cpp file(s)!</span></div>
<div class="line"><a id="l00032" name="l00032"></a><span class="lineno">   32</span><span class="comment"> * Therefore enforce it by failing compile unless compiler&#39;s C++17 or newer mode is in use.</span></div>
<div class="line"><a id="l00033" name="l00033"></a><span class="lineno">   33</span><span class="comment"> *</span></div>
<div class="line"><a id="l00034" name="l00034"></a><span class="lineno">   34</span><span class="comment"> * Note this isn&#39;t academic; as of this writing there&#39;s at least a C++14-requiring constexpr feature in use in one</span></div>
<div class="line"><a id="l00035" name="l00035"></a><span class="lineno">   35</span><span class="comment"> * of the headers.  So at least C++14 has been required for ages in actual practice.  Later, notched it up to C++17</span></div>
<div class="line"><a id="l00036" name="l00036"></a><span class="lineno">   36</span><span class="comment"> * by similar logic. */</span></div>
<div class="line"><a id="l00037" name="l00037"></a><span class="lineno">   37</span><span class="preprocessor">#if (!defined(__cplusplus)) || (__cplusplus &lt; 201703L)</span></div>
<div class="line"><a id="l00038" name="l00038"></a><span class="lineno">   38</span><span class="comment">// Would use static_assert(false), but... it&#39;s C++11 and later only.  So.</span></div>
<div class="line"><a id="l00039" name="l00039"></a><span class="lineno">   39</span><span class="preprocessor">#  error &quot;To compile a translation unit that `#include`s any ipc/ API headers, use C++17 compile mode or later.&quot;</span></div>
<div class="line"><a id="l00040" name="l00040"></a><span class="lineno">   40</span><span class="preprocessor">#endif</span></div>
<div class="line"><a id="l00041" name="l00041"></a><span class="lineno">   41</span><span class="comment"></span> </div>
<div class="line"><a id="l00042" name="l00042"></a><span class="lineno">   42</span><span class="comment">/**</span></div>
<div class="line"><a id="l00043" name="l00043"></a><span class="lineno">   43</span><span class="comment"> * Catch-all namespace for the Flow-IPC project: A library/API in modern C++17 providing high-performance</span></div>
<div class="line"><a id="l00044" name="l00044"></a><span class="lineno">   44</span><span class="comment"> * communication between processes.  It includes schema-based structured message definition and zero-copy transport</span></div>
<div class="line"><a id="l00045" name="l00045"></a><span class="lineno">   45</span><span class="comment"> * between processes.  It also includes a SHared Memory (SHM) module for direct allocation and related needs; and</span></div>
<div class="line"><a id="l00046" name="l00046"></a><span class="lineno">   46</span><span class="comment"> * particular support for passing references to such *bulk* objects through the aforementioned messaging transport</span></div>
<div class="line"><a id="l00047" name="l00047"></a><span class="lineno">   47</span><span class="comment"> * system.</span></div>
<div class="line"><a id="l00048" name="l00048"></a><span class="lineno">   48</span><span class="comment"> *</span></div>
<div class="line"><a id="l00049" name="l00049"></a><span class="lineno">   49</span><span class="comment"> * @note Nomenclature: The project is called Flow-IPC.</span></div>
<div class="line"><a id="l00050" name="l00050"></a><span class="lineno">   50</span><span class="comment"> *</span></div>
<div class="line"><a id="l00051" name="l00051"></a><span class="lineno">   51</span><span class="comment"> * From the user&#39;s perspective, one should view this namespace as the &quot;root,&quot; meaning it consists of two parts:</span></div>
<div class="line"><a id="l00052" name="l00052"></a><span class="lineno">   52</span><span class="comment"> *   - Symbols directly in Flow-IPC: The absolute most basic, commonly used symbols (such as the alias</span></div>
<div class="line"><a id="l00053" name="l00053"></a><span class="lineno">   53</span><span class="comment"> *     ipc::Error_code).  There should be only a handful of these, and they are likely to be small.</span></div>
<div class="line"><a id="l00054" name="l00054"></a><span class="lineno">   54</span><span class="comment"> *     - In particular this includes `enum class` ipc::Log_component which defines the set of possible</span></div>
<div class="line"><a id="l00055" name="l00055"></a><span class="lineno">   55</span><span class="comment"> *       `flow::log::Component` values logged from within all modules of Flow-IPC.  See end of common.hpp.</span></div>
<div class="line"><a id="l00056" name="l00056"></a><span class="lineno">   56</span><span class="comment"> *   - Sub-namespaces (like ipc::transport, ipc::util), each of which represents an Flow-IPC *module* providing</span></div>
<div class="line"><a id="l00057" name="l00057"></a><span class="lineno">   57</span><span class="comment"> *     certain grouped functionality.  The modules are discussed just below.</span></div>
<div class="line"><a id="l00058" name="l00058"></a><span class="lineno">   58</span><span class="comment"> *</span></div>
<div class="line"><a id="l00059" name="l00059"></a><span class="lineno">   59</span><span class="comment"> * Flow-IPC modules overview</span></div>
<div class="line"><a id="l00060" name="l00060"></a><span class="lineno">   60</span><span class="comment"> * ---------------------------</span></div>
<div class="line"><a id="l00061" name="l00061"></a><span class="lineno">   61</span><span class="comment"> * Unlike with, say, Boost or Flow, the user of Flow-IPC should be familiar with the totality of its modules.  They&#39;re</span></div>
<div class="line"><a id="l00062" name="l00062"></a><span class="lineno">   62</span><span class="comment"> * interrelated and to be used together in a typical application.  Contrast with how one might use</span></div>
<div class="line"><a id="l00063" name="l00063"></a><span class="lineno">   63</span><span class="comment"> * `flow::log` but not `flow::async`, or boost.asio but not boost.random.  Summary of modules follows:</span></div>
<div class="line"><a id="l00064" name="l00064"></a><span class="lineno">   64</span><span class="comment"> *</span></div>
<div class="line"><a id="l00065" name="l00065"></a><span class="lineno">   65</span><span class="comment"> *   - *ipc::transport*:</span></div>
<div class="line"><a id="l00066" name="l00066"></a><span class="lineno">   66</span><span class="comment"> *     It allows for low-level (unstructured) and structured message passing between each given pair of</span></div>
<div class="line"><a id="l00067" name="l00067"></a><span class="lineno">   67</span><span class="comment"> *     processes A and B.  This is really *the point* of Flow-IPC, meaning wanting to use ipc::transport is the reason</span></div>
<div class="line"><a id="l00068" name="l00068"></a><span class="lineno">   68</span><span class="comment"> *     one links/includes Flow-IPC in their application in the first place.</span></div>
<div class="line"><a id="l00069" name="l00069"></a><span class="lineno">   69</span><span class="comment"> *     - *ipc::transport::struc* contains the structured-message facilities.  To define a structured message,</span></div>
<div class="line"><a id="l00070" name="l00070"></a><span class="lineno">   70</span><span class="comment"> *       the user is expected to write a *schema* for it.  As of this writing schemas</span></div>
<div class="line"><a id="l00071" name="l00071"></a><span class="lineno">   71</span><span class="comment"> *       are to be written in the Cap&#39;n Proto (capnp) domain-specific language (DSL).  Hence ipc::transport::struc has</span></div>
<div class="line"><a id="l00072" name="l00072"></a><span class="lineno">   72</span><span class="comment"> *       capnp as a dependency.</span></div>
<div class="line"><a id="l00073" name="l00073"></a><span class="lineno">   73</span><span class="comment"> *       - *ipc::transport::struc::shm* contains some important items, albeit not ones *typically* directly mentioned</span></div>
<div class="line"><a id="l00074" name="l00074"></a><span class="lineno">   74</span><span class="comment"> *         by user code, that power the ability to place structured messages directly in SHM, thus enabling end-to-end</span></div>
<div class="line"><a id="l00075" name="l00075"></a><span class="lineno">   75</span><span class="comment"> *         *zero-copy* of all messages passed through transport::struc::Channel.</span></div>
<div class="line"><a id="l00076" name="l00076"></a><span class="lineno">   76</span><span class="comment"> *   - *ipc::session*:</span></div>
<div class="line"><a id="l00077" name="l00077"></a><span class="lineno">   77</span><span class="comment"> *     Before a given process pair A and B talks via ipc::transport, they (typically) will want to establish a</span></div>
<div class="line"><a id="l00078" name="l00078"></a><span class="lineno">   78</span><span class="comment"> *     broad conceptual connection (called a *session*) within the context of which all</span></div>
<div class="line"><a id="l00079" name="l00079"></a><span class="lineno">   79</span><span class="comment"> *     the talking occurs.  ipc::session is concerned with establishing</span></div>
<div class="line"><a id="l00080" name="l00080"></a><span class="lineno">   80</span><span class="comment"> *     such sessions, so that most user code can then mostly forget about that and use ipc::transport to communicate.</span></div>
<div class="line"><a id="l00081" name="l00081"></a><span class="lineno">   81</span><span class="comment"> *     It includes safety measures like authentication/tokens, but these should be mostly invisible in day-to-day coding</span></div>
<div class="line"><a id="l00082" name="l00082"></a><span class="lineno">   82</span><span class="comment"> *     of IPC logic via ipc::transport.  It *is* possible to establish ipc::transport pipes without sessions, and</span></div>
<div class="line"><a id="l00083" name="l00083"></a><span class="lineno">   83</span><span class="comment"> *     for smaller and/or legacy applications and/or prototyping that may be a reasonable approach.</span></div>
<div class="line"><a id="l00084" name="l00084"></a><span class="lineno">   84</span><span class="comment"> *     - *ipc::session::shm* conventionally contains SHM-enabled session functionality.  The location of a</span></div>
<div class="line"><a id="l00085" name="l00085"></a><span class="lineno">   85</span><span class="comment"> *       given set of classes will mirror the ipc::shm facilities to which those SHM-enabled sessions provides access.</span></div>
<div class="line"><a id="l00086" name="l00086"></a><span class="lineno">   86</span><span class="comment"> *       For example ipc::session::shm::classic contains SHM-classic sessions which provide access to arenas</span></div>
<div class="line"><a id="l00087" name="l00087"></a><span class="lineno">   87</span><span class="comment"> *       supplied by ipc::shm::classic.  Similarly ipc::session::shm::arena_lend::jemalloc contains SHM-jemalloc</span></div>
<div class="line"><a id="l00088" name="l00088"></a><span class="lineno">   88</span><span class="comment"> *       sessions &lt;=&gt; core arena facilities in ipc::shm::arena_lend::jemalloc.  Note the 1-1 naming of namespaces in</span></div>
<div class="line"><a id="l00089" name="l00089"></a><span class="lineno">   89</span><span class="comment"> *       both cases.</span></div>
<div class="line"><a id="l00090" name="l00090"></a><span class="lineno">   90</span><span class="comment"> *   - *ipc::shm*:</span></div>
<div class="line"><a id="l00091" name="l00091"></a><span class="lineno">   91</span><span class="comment"> *     It provides explicit shared memory (SHM) functionality, including allocating in SHM -- vaguely</span></div>
<div class="line"><a id="l00092" name="l00092"></a><span class="lineno">   92</span><span class="comment"> *     analogously to using the regular heap.  ipc::shm and ipc::transport are co-designed to support transmitting</span></div>
<div class="line"><a id="l00093" name="l00093"></a><span class="lineno">   93</span><span class="comment"> *     references to SHM-stored objects.  ipc::session treats setup of SHM arenas for (direct or background) use</span></div>
<div class="line"><a id="l00094" name="l00094"></a><span class="lineno">   94</span><span class="comment"> *     in a given session as an important, albeit optional, capability.  Unless the user wants to explicitly</span></div>
<div class="line"><a id="l00095" name="l00095"></a><span class="lineno">   95</span><span class="comment"> *     place data structures (such as `struct`s and STL containers) into SHM -- which is an advanced but sometimes</span></div>
<div class="line"><a id="l00096" name="l00096"></a><span class="lineno">   96</span><span class="comment"> *     desirable capability -- direct use of ipc::shm is not necessary.</span></div>
<div class="line"><a id="l00097" name="l00097"></a><span class="lineno">   97</span><span class="comment"> *   - *ipc::util*: Miscellaneous items.  That said some of these are quite important and oft-used throughout other</span></div>
<div class="line"><a id="l00098" name="l00098"></a><span class="lineno">   98</span><span class="comment"> *     modules.  Here we single out, in particular, ipc::util::Shared_name and ipc::util::Native_handle.</span></div>
<div class="line"><a id="l00099" name="l00099"></a><span class="lineno">   99</span><span class="comment"> *</span></div>
<div class="line"><a id="l00100" name="l00100"></a><span class="lineno">  100</span><span class="comment"> * @note Nomenclature: We refer to Cap&#39;n Proto as capnp, lower-case, no backticks.  Keep to this consistent convention</span></div>
<div class="line"><a id="l00101" name="l00101"></a><span class="lineno">  101</span><span class="comment"> *       in comments.</span></div>
<div class="line"><a id="l00102" name="l00102"></a><span class="lineno">  102</span><span class="comment"> *</span></div>
<div class="line"><a id="l00103" name="l00103"></a><span class="lineno">  103</span><span class="comment"> * The above text views Flow-IPC somewhat as a monolithic whole.  Indeed the present documentation generally treats</span></div>
<div class="line"><a id="l00104" name="l00104"></a><span class="lineno">  104</span><span class="comment"> * the entirety of Flow-IPC as available and usable, even though the are various sub-namespaces as shown that break</span></div>
<div class="line"><a id="l00105" name="l00105"></a><span class="lineno">  105</span><span class="comment"> * the monolith into cooperating modules.  When it comes to practical needs, this view is sufficient.  Really, most</span></div>
<div class="line"><a id="l00106" name="l00106"></a><span class="lineno">  106</span><span class="comment"> * users will (1) start a session (using ipc::session::shm for max performance), (2) use the session to create</span></div>
<div class="line"><a id="l00107" name="l00107"></a><span class="lineno">  107</span><span class="comment"> * 1+ ipc::transport::Channel, (3) typically upgrade each to ipc::transport::struc::Channel immediately (a one-liner),</span></div>
<div class="line"><a id="l00108" name="l00108"></a><span class="lineno">  108</span><span class="comment"> * (3) use the `struc::Channel` API to send/receive messages with automatic end-to-end zero-copy performance.</span></div>
<div class="line"><a id="l00109" name="l00109"></a><span class="lineno">  109</span><span class="comment"> * (4) Optionally one can also access a SHM-arena for direct C++ object placement and access in SHM; the SHM arenas</span></div>
<div class="line"><a id="l00110" name="l00110"></a><span class="lineno">  110</span><span class="comment"> * are available from the session object.</span></div>
<div class="line"><a id="l00111" name="l00111"></a><span class="lineno">  111</span><span class="comment"> *</span></div>
<div class="line"><a id="l00112" name="l00112"></a><span class="lineno">  112</span><span class="comment"> * That said, read on if you want to maintain or otherwise deeper understand Flow-IPC.  There&#39;s a deeper organization</span></div>
<div class="line"><a id="l00113" name="l00113"></a><span class="lineno">  113</span><span class="comment"> * of this monolith, in which one builds up the whole out of smaller parts, where we generally avoid circular</span></div>
<div class="line"><a id="l00114" name="l00114"></a><span class="lineno">  114</span><span class="comment"> * dependencies (A needs B, and B needs A).  Let&#39;s briefly go through the process of naming the most basic parts and</span></div>
<div class="line"><a id="l00115" name="l00115"></a><span class="lineno">  115</span><span class="comment"> * then showing what depends on them, and so on, until everything is listed in bottom-up order.  To wit:</span></div>
<div class="line"><a id="l00116" name="l00116"></a><span class="lineno">  116</span><span class="comment"> *</span></div>
<div class="line"><a id="l00117" name="l00117"></a><span class="lineno">  117</span><span class="comment"> *   -# ipc::util: This contains basic, simple building blocks.  ipc::util::Shared_name is used to name various</span></div>
<div class="line"><a id="l00118" name="l00118"></a><span class="lineno">  118</span><span class="comment"> *      shared resource throughout Flow-IPC.  ipc::util::Native_handle is a trivial wrapper around a native handle</span></div>
<div class="line"><a id="l00119" name="l00119"></a><span class="lineno">  119</span><span class="comment"> *      (FD in POSIX/Linux/Unix parlance).  There are various other items which you&#39;ll note when they&#39;re mentioned.</span></div>
<div class="line"><a id="l00120" name="l00120"></a><span class="lineno">  120</span><span class="comment"> *      - Dependents: Essentially all other code routinely depends on ipc::util.</span></div>
<div class="line"><a id="l00121" name="l00121"></a><span class="lineno">  121</span><span class="comment"> *   -# ipc::transport, *excluding* ipc::transport::struc: This is the transport *core layer*.  Think of</span></div>
<div class="line"><a id="l00122" name="l00122"></a><span class="lineno">  122</span><span class="comment"> *      this as wrappers around legacy IPC transport APIs with which you may already be familiar: e.g., Unix domain</span></div>
<div class="line"><a id="l00123" name="l00123"></a><span class="lineno">  123</span><span class="comment"> *      sockets.  There are key concepts, including ipc::transport::Blob_sender and `Blob_receiver`</span></div>
<div class="line"><a id="l00124" name="l00124"></a><span class="lineno">  124</span><span class="comment"> *      (+ `Native_handle_{send|receiv}er`); and their implementations over the aforementioned specific low-level</span></div>
<div class="line"><a id="l00125" name="l00125"></a><span class="lineno">  125</span><span class="comment"> *      transports (Unix domain sockets, MQs as of this writing).</span></div>
<div class="line"><a id="l00126" name="l00126"></a><span class="lineno">  126</span><span class="comment"> *      - Dependents:</span></div>
<div class="line"><a id="l00127" name="l00127"></a><span class="lineno">  127</span><span class="comment"> *        - ipc::transport::struc.  The key point is `transport::struc::Channel`,</span></div>
<div class="line"><a id="l00128" name="l00128"></a><span class="lineno">  128</span><span class="comment"> *          the absolute most important object (possibly in all of Flow-IPC), adapts `transport::Channel`, including</span></div>
<div class="line"><a id="l00129" name="l00129"></a><span class="lineno">  129</span><span class="comment"> *          for example leveraging that an unstructured `Channel` might contain a blobs pipe *and* a native handles</span></div>
<div class="line"><a id="l00130" name="l00130"></a><span class="lineno">  130</span><span class="comment"> *          pipe.</span></div>
<div class="line"><a id="l00131" name="l00131"></a><span class="lineno">  131</span><span class="comment"> *        - ipc::session depends on ipc::transport, in that the most important function of an ipc::session::Session</span></div>
<div class="line"><a id="l00132" name="l00132"></a><span class="lineno">  132</span><span class="comment"> *          is to *painlessly create* (open) ipc::transport::Channel objects.  You start a session to the opposing</span></div>
<div class="line"><a id="l00133" name="l00133"></a><span class="lineno">  133</span><span class="comment"> *          process; and you use that session to create 1+ channels; then you speak over these channels as needed.</span></div>
<div class="line"><a id="l00134" name="l00134"></a><span class="lineno">  134</span><span class="comment"> *          (*If* you want to speak using structured messages, you upgrade a `transport::Channel` to a</span></div>
<div class="line"><a id="l00135" name="l00135"></a><span class="lineno">  135</span><span class="comment"> *          `transport::struc::Channel`: a structured channel.)</span></div>
<div class="line"><a id="l00136" name="l00136"></a><span class="lineno">  136</span><span class="comment"> *   -# ipc::transport::struc: The transport *structured layer* builds on top of (1) the core layer and (2) capnp.</span></div>
<div class="line"><a id="l00137" name="l00137"></a><span class="lineno">  137</span><span class="comment"> *      `struc::Channel` adapts an unstructured `Channel`, allowing efficient transmission of structured messages</span></div>
<div class="line"><a id="l00138" name="l00138"></a><span class="lineno">  138</span><span class="comment"> *      filled-out according to user-provided capnp-generated schema(s).  At its simplest, wihout the (spoiler alert)</span></div>
<div class="line"><a id="l00139" name="l00139"></a><span class="lineno">  139</span><span class="comment"> *      `shm` sub-namespace, an out-message is backed by the regular heap (`new`, etc.); and a received in-message is</span></div>
<div class="line"><a id="l00140" name="l00140"></a><span class="lineno">  140</span><span class="comment"> *      a copy also backed by the regular heap of the recipient process.</span></div>
<div class="line"><a id="l00141" name="l00141"></a><span class="lineno">  141</span><span class="comment"> *      - Dependents: ipc::session and ipc::session::shm::arena_lend, for orthogonal reasons, use</span></div>
<div class="line"><a id="l00142" name="l00142"></a><span class="lineno">  142</span><span class="comment"> *        ipc::transport::struc::Channel for their internal purposes.  It&#39;s a useful guy!</span></div>
<div class="line"><a id="l00143" name="l00143"></a><span class="lineno">  143</span><span class="comment"> *   -# ipc::session, *excluding* ipc::session::shm: This is the core support for sessions, which are how one painlessly</span></div>
<div class="line"><a id="l00144" name="l00144"></a><span class="lineno">  144</span><span class="comment"> *      begins a conversation between your process and the opposing process.  Without it you&#39;ll need to worry about</span></div>
<div class="line"><a id="l00145" name="l00145"></a><span class="lineno">  145</span><span class="comment"> *      low-level resource naming and cleanup; with it, it&#39;s taken care-of -- just open channels and use them.</span></div>
<div class="line"><a id="l00146" name="l00146"></a><span class="lineno">  146</span><span class="comment"> *      Spoiler alert: the sub-namespace `shm` (see below) will add SHM capabilities.</span></div>
<div class="line"><a id="l00147" name="l00147"></a><span class="lineno">  147</span><span class="comment"> *      - Dependents: ipc::session::shm builds on top of this and hence depends on it.</span></div>
<div class="line"><a id="l00148" name="l00148"></a><span class="lineno">  148</span><span class="comment"> *   -# ipc::shm::stl: A couple of key facilities here enable storage of STL-compliant C++ data structures directly</span></div>
<div class="line"><a id="l00149" name="l00149"></a><span class="lineno">  149</span><span class="comment"> *      in SHM; e.g., a map from strings to vectors of strings and `struct`s and... etc.  You, the user, will *only*</span></div>
<div class="line"><a id="l00150" name="l00150"></a><span class="lineno">  150</span><span class="comment"> *      directly use this, if you need such functionality.  If you only need to send structured messages with max</span></div>
<div class="line"><a id="l00151" name="l00151"></a><span class="lineno">  151</span><span class="comment"> *      perf (which internally is achieved using SHM), then you need not directly mention this.</span></div>
<div class="line"><a id="l00152" name="l00152"></a><span class="lineno">  152</span><span class="comment"> *      - Dependents:</span></div>
<div class="line"><a id="l00153" name="l00153"></a><span class="lineno">  153</span><span class="comment"> *        - ipc::transport::struc::shm &quot;eats our own dog food&quot; by internally representing certain data</span></div>
<div class="line"><a id="l00154" name="l00154"></a><span class="lineno">  154</span><span class="comment"> *          structures using STL-compliant APIs, including `list&lt;&gt;` and `flow::util::Blob`.</span></div>
<div class="line"><a id="l00155" name="l00155"></a><span class="lineno">  155</span><span class="comment"> *   -# ipc::transport::struc::shm: This essentially just adds `shm::Builder` and `shm::Reader` which are impls</span></div>
<div class="line"><a id="l00156" name="l00156"></a><span class="lineno">  156</span><span class="comment"> *      of ipc::transport::struc::Struct_builder and `Struct_reader` concepts that enable end-to-end zero-copy</span></div>
<div class="line"><a id="l00157" name="l00157"></a><span class="lineno">  157</span><span class="comment"> *      transmission of any capnp-schema-based message -- as long as one has certain key SHM-enabling objects, most</span></div>
<div class="line"><a id="l00158" name="l00158"></a><span class="lineno">  158</span><span class="comment"> *      notably a `Shm_arena`.</span></div>
<div class="line"><a id="l00159" name="l00159"></a><span class="lineno">  159</span><span class="comment"> *      - Dependents:</span></div>
<div class="line"><a id="l00160" name="l00160"></a><span class="lineno">  160</span><span class="comment"> *        - ipc::session::shm mentions `shm::Builder` and `shm::Reader` in a key convenience alias.</span></div>
<div class="line"><a id="l00161" name="l00161"></a><span class="lineno">  161</span><span class="comment"> *        - The bottom line is, if you use SHM-enabled sessions -- which is at least easily the most convenient way</span></div>
<div class="line"><a id="l00162" name="l00162"></a><span class="lineno">  162</span><span class="comment"> *          to obtain end-to-end zero-copy perf when transmitting structured messages along channels -- then</span></div>
<div class="line"><a id="l00163" name="l00163"></a><span class="lineno">  163</span><span class="comment"> *          ipc::transport::struc::shm shall be used, most likely without your needing to mention it or worry about it.</span></div>
<div class="line"><a id="l00164" name="l00164"></a><span class="lineno">  164</span><span class="comment"> *   -# ipc::shm::classic: This is a *SHM-provider* (of SHM-arenas); namely the *SHM-classic* provider.  The core item</span></div>
<div class="line"><a id="l00165" name="l00165"></a><span class="lineno">  165</span><span class="comment"> *      is ipc::shm::classic::Pool_arena, a &quot;classic&quot; single-segment (pool) SHM arena with a simple arena-allocation</span></div>
<div class="line"><a id="l00166" name="l00166"></a><span class="lineno">  166</span><span class="comment"> *      algorithm.</span></div>
<div class="line"><a id="l00167" name="l00167"></a><span class="lineno">  167</span><span class="comment"> *      - Dependents: ipc::session::shm::classic provides SHM-enabled sessions with this SHM-provider as the</span></div>
<div class="line"><a id="l00168" name="l00168"></a><span class="lineno">  168</span><span class="comment"> *        required SHM engine.  Naturally in so doing it depends on ipc::shm::classic, especially `classic::Pool_arena`.</span></div>
<div class="line"><a id="l00169" name="l00169"></a><span class="lineno">  169</span><span class="comment"> *   -# ipc::shm::arena_lend (more specifically ipc::shm::arena_lend::jemalloc): This is the other *SHM-provider*</span></div>
<div class="line"><a id="l00170" name="l00170"></a><span class="lineno">  170</span><span class="comment"> *      (of SHM-arenas); namely the *SHM-jemalloc* provider.  The core item is `jemalloc::Ipc_arena`.</span></div>
<div class="line"><a id="l00171" name="l00171"></a><span class="lineno">  171</span><span class="comment"> *      is `Pool_arena`, a &quot;classic&quot; single-segment (pool) SHM arena with a simple arena-allocation algorithm.</span></div>
<div class="line"><a id="l00172" name="l00172"></a><span class="lineno">  172</span><span class="comment"> *      - Dependents: ipc::session::shm::arena_lend::jemalloc provides SHM-enabled sessions with this SHM-provider as</span></div>
<div class="line"><a id="l00173" name="l00173"></a><span class="lineno">  173</span><span class="comment"> *        the required SHM engine.  Naturally in so doing it depends on ipc::shm::arena_lend::jemalloc,</span></div>
<div class="line"><a id="l00174" name="l00174"></a><span class="lineno">  174</span><span class="comment"> *        especially `jemalloc::Ipc_arena`.</span></div>
<div class="line"><a id="l00175" name="l00175"></a><span class="lineno">  175</span><span class="comment"> *   -# ipc::session::shm: This namespace adds SHM-enabled sessions.  Namely that adds two capabilities; one, to</span></div>
<div class="line"><a id="l00176" name="l00176"></a><span class="lineno">  176</span><span class="comment"> *      easily get end-to-end zero-copy performance along `struc::Channel` objects opened via these sessions.  And,</span></div>
<div class="line"><a id="l00177" name="l00177"></a><span class="lineno">  177</span><span class="comment"> *      optionally, two: To have direct access to SHM-arena(s) in which to place and access C++ objects.</span></div>
<div class="line"><a id="l00178" name="l00178"></a><span class="lineno">  178</span><span class="comment"> *      - More specifically: ipc::session::shm::classic = SHM-classic-provider-enabled sessions;</span></div>
<div class="line"><a id="l00179" name="l00179"></a><span class="lineno">  179</span><span class="comment"> *        ipc::session::shm::arena_lend::jemalloc = SHM-jemalloc-provider-enabled sessions.</span></div>
<div class="line"><a id="l00180" name="l00180"></a><span class="lineno">  180</span><span class="comment"> *        - Dependents: none (inside Flow-IPC).</span></div>
<div class="line"><a id="l00181" name="l00181"></a><span class="lineno">  181</span><span class="comment"> *</span></div>
<div class="line"><a id="l00182" name="l00182"></a><span class="lineno">  182</span><span class="comment"> * Again -- there&#39;s no need to understand all this, if you&#39;re just using Flow-IPC in the expected mainstream ways.</span></div>
<div class="line"><a id="l00183" name="l00183"></a><span class="lineno">  183</span><span class="comment"> * Nevertheless it could be a useful, if wordy, map to the building blocks of Flow-IPC and how they interact.</span></div>
<div class="line"><a id="l00184" name="l00184"></a><span class="lineno">  184</span><span class="comment"> *</span></div>
<div class="line"><a id="l00185" name="l00185"></a><span class="lineno">  185</span><span class="comment"> * Distributed sub-components (libraries)</span></div>
<div class="line"><a id="l00186" name="l00186"></a><span class="lineno">  186</span><span class="comment"> * --------------------------------------</span></div>
<div class="line"><a id="l00187" name="l00187"></a><span class="lineno">  187</span><span class="comment"> * The above describes Flow-IPC as a whole.  Generally we recommend a distribution of Flow-IPC which includes all</span></div>
<div class="line"><a id="l00188" name="l00188"></a><span class="lineno">  188</span><span class="comment"> * the pieces, to be used at will.  That said, for reasons outside our scope here, this project is actually distributed</span></div>
<div class="line"><a id="l00189" name="l00189"></a><span class="lineno">  189</span><span class="comment"> * in a few parts, each of which is a library with a set of header files.  (The generated documentation is created</span></div>
<div class="line"><a id="l00190" name="l00190"></a><span class="lineno">  190</span><span class="comment"> * from all of them together, and therefore various comments aren&#39;t particularly shy about referring to items across</span></div>
<div class="line"><a id="l00191" name="l00191"></a><span class="lineno">  191</span><span class="comment"> * the boundaries between those parts.)  These parts (libraries) are:</span></div>
<div class="line"><a id="l00192" name="l00192"></a><span class="lineno">  192</span><span class="comment"> *</span></div>
<div class="line"><a id="l00193" name="l00193"></a><span class="lineno">  193</span><span class="comment"> *   - `ipc_core`: Contains: ipc::util, ipc::transport (excluding ipc::transport::struc).</span></div>
<div class="line"><a id="l00194" name="l00194"></a><span class="lineno">  194</span><span class="comment"> *   - `ipc_transport_structured`: Contains: ipc::transport::struc (excluding ipc::transport::struc::shm).</span></div>
<div class="line"><a id="l00195" name="l00195"></a><span class="lineno">  195</span><span class="comment"> *   - `ipc_session`: Contains: ipc::session (excluding ipc::session::shm).</span></div>
<div class="line"><a id="l00196" name="l00196"></a><span class="lineno">  196</span><span class="comment"> *   - `ipc_shm`: Contains: ipc::shm::stl, ipc::transport::struc::shm</span></div>
<div class="line"><a id="l00197" name="l00197"></a><span class="lineno">  197</span><span class="comment"> *                          (including ipc::transport::struc::shm::classic but excluding all other</span></div>
<div class="line"><a id="l00198" name="l00198"></a><span class="lineno">  198</span><span class="comment"> *                          such sub-namespaces),</span></div>
<div class="line"><a id="l00199" name="l00199"></a><span class="lineno">  199</span><span class="comment"> *                          ipc::shm::classic + ipc::session::shm::classic.</span></div>
<div class="line"><a id="l00200" name="l00200"></a><span class="lineno">  200</span><span class="comment"> *   - `ipc_shm_arena_lend`: Contains: ipc::transport::struc::shm::arena_lend,</span></div>
<div class="line"><a id="l00201" name="l00201"></a><span class="lineno">  201</span><span class="comment"> *                                     ipc::shm::arena_lend + ipc::session::shm::arena_lend.</span></div>
<div class="line"><a id="l00202" name="l00202"></a><span class="lineno">  202</span><span class="comment"> *</span></div>
<div class="line"><a id="l00203" name="l00203"></a><span class="lineno">  203</span><span class="comment"> * The dependencies between these are as follows:</span></div>
<div class="line"><a id="l00204" name="l00204"></a><span class="lineno">  204</span><span class="comment"> *   - `ipc_core` &lt;- each of the others;</span></div>
<div class="line"><a id="l00205" name="l00205"></a><span class="lineno">  205</span><span class="comment"> *   - `ipc_transport_structured` &lt;- `ipc_session` &lt;- `ipc_shm` &lt;- `ipc_shm_arena_lend`.</span></div>
<div class="line"><a id="l00206" name="l00206"></a><span class="lineno">  206</span><span class="comment"> *     - (There are are, e.g., direct dependencies redundant to the above, such as how `ipc_shm_arena_lend`</span></div>
<div class="line"><a id="l00207" name="l00207"></a><span class="lineno">  207</span><span class="comment"> *       depends on `ipc_transport_structured` in certain key internal impl details.  We are not pointing out every</span></div>
<div class="line"><a id="l00208" name="l00208"></a><span class="lineno">  208</span><span class="comment"> *       direct dependency here, leaving it out as long as it&#39;s implied by another indirect dependency such</span></div>
<div class="line"><a id="l00209" name="l00209"></a><span class="lineno">  209</span><span class="comment"> *       as `ipc_shm_arena_lend` indirectly depending on `ipc_transport_structured` via several others. )</span></div>
<div class="line"><a id="l00210" name="l00210"></a><span class="lineno">  210</span><span class="comment"> *</span></div>
<div class="line"><a id="l00211" name="l00211"></a><span class="lineno">  211</span><span class="comment"> * Each one, in the source code, is in a separate top-level directory; and generates a separate static library.</span></div>
<div class="line"><a id="l00212" name="l00212"></a><span class="lineno">  212</span><span class="comment"> * However, their directory structures -- and accordingly the namespace trees -- overlap in naming, which</span></div>
<div class="line"><a id="l00213" name="l00213"></a><span class="lineno">  213</span><span class="comment"> * manifests itself when 2 or more of the sub-components are installed together.  For example `ipc_session`</span></div>
<div class="line"><a id="l00214" name="l00214"></a><span class="lineno">  214</span><span class="comment"> * places `ipc/session` into the `#include` tree; and `ipc_shm` places `ipc/session/shm/classic` within that.</span></div>
<div class="line"><a id="l00215" name="l00215"></a><span class="lineno">  215</span><span class="comment"> *</span></div>
<div class="line"><a id="l00216" name="l00216"></a><span class="lineno">  216</span><span class="comment"> * Relationship with Flow and Boost</span></div>
<div class="line"><a id="l00217" name="l00217"></a><span class="lineno">  217</span><span class="comment"> * --------------------------------</span></div>
<div class="line"><a id="l00218" name="l00218"></a><span class="lineno">  218</span><span class="comment"> * Flow-IPC requires Flow and Boost, not only for internal implementation purposes but also in some of its APIs.</span></div>
<div class="line"><a id="l00219" name="l00219"></a><span class="lineno">  219</span><span class="comment"> * For example, `flow::log` is the assumed logging system, and `flow::Error_code` and related conventions are used</span></div>
<div class="line"><a id="l00220" name="l00220"></a><span class="lineno">  220</span><span class="comment"> * for error reporting; and `boost::interprocess` and `boost::thread` APIs may be exposed at times.</span></div>
<div class="line"><a id="l00221" name="l00221"></a><span class="lineno">  221</span><span class="comment"> *</span></div>
<div class="line"><a id="l00222" name="l00222"></a><span class="lineno">  222</span><span class="comment"> * Moreover, Flow-IPC shares Flow &quot;DNA&quot; in terms of coding style, error, logging, documentation, etc., conventions.</span></div>
<div class="line"><a id="l00223" name="l00223"></a><span class="lineno">  223</span><span class="comment"> * Flow-IPC and Flow itself are also more loosely inspired by Boost &quot;DNA.&quot;  (For example: `snake_case` for identifier</span></div>
<div class="line"><a id="l00224" name="l00224"></a><span class="lineno">  224</span><span class="comment"> * naming is inherited from Flow, which inherits it more loosely from Boost; the error reporting API convention is taken</span></div>
<div class="line"><a id="l00225" name="l00225"></a><span class="lineno">  225</span><span class="comment"> * from Flow which uses a modified version of the boost.asio convention.)</span></div>
<div class="line"><a id="l00226" name="l00226"></a><span class="lineno">  226</span><span class="comment"> *</span></div>
<div class="line"><a id="l00227" name="l00227"></a><span class="lineno">  227</span><span class="comment"> * Documentation / Doxygen</span></div>
<div class="line"><a id="l00228" name="l00228"></a><span class="lineno">  228</span><span class="comment"> * -----------------------</span></div>
<div class="line"><a id="l00229" name="l00229"></a><span class="lineno">  229</span><span class="comment"> * All code in the project proper follows a high standard of documentation, almost solely via comments therein</span></div>
<div class="line"><a id="l00230" name="l00230"></a><span class="lineno">  230</span><span class="comment"> * (plus a guided Manual in manual/....dox.txt files, also as Doxygen-read comments).</span></div>
<div class="line"><a id="l00231" name="l00231"></a><span class="lineno">  231</span><span class="comment"> * The standards and mechanics w/r/t documentation are entirely inherited from Flow.  Therefore, see the</span></div>
<div class="line"><a id="l00232" name="l00232"></a><span class="lineno">  232</span><span class="comment"> * `namespace flow` doc header&#39;s &quot;Documentation / Doxygen&quot; section.  It applies</span></div>
<div class="line"><a id="l00233" name="l00233"></a><span class="lineno">  233</span><span class="comment"> * verbatim here (within reason).  (Spoiler alert: Doc header comments on most entities (classes, functions, ...) are</span></div>
<div class="line"><a id="l00234" name="l00234"></a><span class="lineno">  234</span><span class="comment"> * friendly to doc web page generation by Doxygen.  Doxygen is a tool similar to Javadoc.)</span></div>
<div class="line"><a id="l00235" name="l00235"></a><span class="lineno">  235</span><span class="comment"> *</span></div>
<div class="line"><a id="l00236" name="l00236"></a><span class="lineno">  236</span><span class="comment"> * The only exception to this is the addition of the aforementioned guided Manual as well which Flow lacks as of</span></div>
<div class="line"><a id="l00237" name="l00237"></a><span class="lineno">  237</span><span class="comment"> * this writing (for the time being).</span></div>
<div class="line"><a id="l00238" name="l00238"></a><span class="lineno">  238</span><span class="comment"> *</span></div>
<div class="line"><a id="l00239" name="l00239"></a><span class="lineno">  239</span><span class="comment"> * Using Flow-IPC modules</span></div>
<div class="line"><a id="l00240" name="l00240"></a><span class="lineno">  240</span><span class="comment"> * ------------------------</span></div>
<div class="line"><a id="l00241" name="l00241"></a><span class="lineno">  241</span><span class="comment"> * This section discusses usability topics that apply to all Flow-IPC modules including hopefully any future ones but</span></div>
<div class="line"><a id="l00242" name="l00242"></a><span class="lineno">  242</span><span class="comment"> * definitely all existing ones as of this writing.</span></div>
<div class="line"><a id="l00243" name="l00243"></a><span class="lineno">  243</span><span class="comment"> *</span></div>
<div class="line"><a id="l00244" name="l00244"></a><span class="lineno">  244</span><span class="comment"> * ### Error reporting ###</span></div>
<div class="line"><a id="l00245" name="l00245"></a><span class="lineno">  245</span><span class="comment"> * The standards and mechanics w/r/t error reporting are entirely</span></div>
<div class="line"><a id="l00246" name="l00246"></a><span class="lineno">  246</span><span class="comment"> * inherited from Flow.  Therefore, see the `namespace flow` doc header&#39;s &quot;Error reporting&quot; section.  It applies</span></div>
<div class="line"><a id="l00247" name="l00247"></a><span class="lineno">  247</span><span class="comment"> * verbatim (within reason) here.</span></div>
<div class="line"><a id="l00248" name="l00248"></a><span class="lineno">  248</span><span class="comment"> *</span></div>
<div class="line"><a id="l00249" name="l00249"></a><span class="lineno">  249</span><span class="comment"> * ### Logging ###</span></div>
<div class="line"><a id="l00250" name="l00250"></a><span class="lineno">  250</span><span class="comment"> * We use the Flow log module, in `flow::log` namespace, for logging.  We are just a consumer, but this does mean</span></div>
<div class="line"><a id="l00251" name="l00251"></a><span class="lineno">  251</span><span class="comment"> * the Flow-IPC user must supply a `flow::log::Logger` into various APIs in order to enable logging.  (Worst-case,</span></div>
<div class="line"><a id="l00252" name="l00252"></a><span class="lineno">  252</span><span class="comment"> * passing `Logger == null` will make it log nowhere.)  See `flow::log` docs.  Spoiler alert: You can hook it up to</span></div>
<div class="line"><a id="l00253" name="l00253"></a><span class="lineno">  253</span><span class="comment"> * whatever logging output/other logging API you desire, or it can log for you in certain common ways including console</span></div>
<div class="line"><a id="l00254" name="l00254"></a><span class="lineno">  254</span><span class="comment"> * and rotated files.</span></div>
<div class="line"><a id="l00255" name="l00255"></a><span class="lineno">  255</span><span class="comment"> *</span></div>
<div class="line"><a id="l00256" name="l00256"></a><span class="lineno">  256</span><span class="comment"> * @internal</span></div>
<div class="line"><a id="l00257" name="l00257"></a><span class="lineno">  257</span><span class="comment"> *</span></div>
<div class="line"><a id="l00258" name="l00258"></a><span class="lineno">  258</span><span class="comment"> * Implementation notes</span></div>
<div class="line"><a id="l00259" name="l00259"></a><span class="lineno">  259</span><span class="comment"> * --------------------</span></div>
<div class="line"><a id="l00260" name="l00260"></a><span class="lineno">  260</span><span class="comment"> * There is a high standard of consistency and style, as well as documentation, in Flow-IPC.  The standards and</span></div>
<div class="line"><a id="l00261" name="l00261"></a><span class="lineno">  261</span><span class="comment"> * mechanics for all such aspects (including source tree org, code style, doc style) are entirely</span></div>
<div class="line"><a id="l00262" name="l00262"></a><span class="lineno">  262</span><span class="comment"> * inherited from Flow.  Therefore, see the `namespace flow` doc header: its analogous sections</span></div>
<div class="line"><a id="l00263" name="l00263"></a><span class="lineno">  263</span><span class="comment"> * apply verbatim here (within reason).</span></div>
<div class="line"><a id="l00264" name="l00264"></a><span class="lineno">  264</span><span class="comment"> *</span></div>
<div class="line"><a id="l00265" name="l00265"></a><span class="lineno">  265</span><span class="comment"> * To-dos and future features</span></div>
<div class="line"><a id="l00266" name="l00266"></a><span class="lineno">  266</span><span class="comment"> * --------------------------</span></div>
<div class="line"><a id="l00267" name="l00267"></a><span class="lineno">  267</span><span class="comment"> * Firstly see `namespace flow` doc header&#39;s similar section.  There&#39;s a good chance each of those to-dos applies</span></div>
<div class="line"><a id="l00268" name="l00268"></a><span class="lineno">  268</span><span class="comment"> * to Flow-IPC as well.  Further general to-dos should be added right here as needed over time.</span></div>
<div class="line"><a id="l00269" name="l00269"></a><span class="lineno">  269</span><span class="comment"> */</span></div>
<div class="line"><a id="l00270" name="l00270"></a><span class="lineno">  270</span><span class="keyword">namespace </span><a class="code hl_namespace" href="namespaceipc.html">ipc</a></div>
<div class="line"><a id="l00271" name="l00271"></a><span class="lineno">  271</span>{</div>
<div class="line"><a id="l00272" name="l00272"></a><span class="lineno">  272</span> </div>
<div class="line"><a id="l00273" name="l00273"></a><span class="lineno">  273</span><span class="comment">// Types.  They&#39;re outside of `namespace ::ipc::util` for brevity due to their frequent use.</span></div>
<div class="line"><a id="l00274" name="l00274"></a><span class="lineno">  274</span> </div>
<div class="line"><a id="l00275" name="l00275"></a><span class="lineno">  275</span><span class="comment">/* (The @namespace and @brief thingies shouldn&#39;t be needed, but some Doxygen bug necessitated them.</span></div>
<div class="line"><a id="l00276" name="l00276"></a><span class="lineno">  276</span><span class="comment"> * See flow::util::bind_ns for explanation... same thing here.) */</span></div>
<div class="line"><a id="l00277" name="l00277"></a><span class="lineno">  277</span><span class="comment"></span> </div>
<div class="line"><a id="l00278" name="l00278"></a><span class="lineno">  278</span><span class="comment">/**</span></div>
<div class="line"><a id="l00279" name="l00279"></a><span class="lineno"><a class="line" href="namespaceipc_1_1bipc.html">  279</a></span><span class="comment"> * @namespace ipc::bipc</span></div>
<div class="line"><a id="l00280" name="l00280"></a><span class="lineno">  280</span><span class="comment"> * @brief Short-hand for boost.interprocess namespace.</span></div>
<div class="line"><a id="l00281" name="l00281"></a><span class="lineno">  281</span><span class="comment"> */</span></div>
<div class="line"><a id="l00282" name="l00282"></a><span class="lineno">  282</span><span class="keyword">namespace </span>bipc = boost::interprocess;</div>
<div class="line"><a id="l00283" name="l00283"></a><span class="lineno">  283</span><span class="comment"></span> </div>
<div class="line"><a id="l00284" name="l00284"></a><span class="lineno">  284</span><span class="comment">/**</span></div>
<div class="line"><a id="l00285" name="l00285"></a><span class="lineno"><a class="line" href="namespaceipc_1_1fs.html">  285</a></span><span class="comment"> * @namespace ipc::fs</span></div>
<div class="line"><a id="l00286" name="l00286"></a><span class="lineno">  286</span><span class="comment"> * @brief Short-hand for `filesystem` namespace.</span></div>
<div class="line"><a id="l00287" name="l00287"></a><span class="lineno">  287</span><span class="comment"> *</span></div>
<div class="line"><a id="l00288" name="l00288"></a><span class="lineno">  288</span><span class="comment"> * ### Rationale for aliasing to `boost::filesystem` instead of `std::filesystem` ###</span></div>
<div class="line"><a id="l00289" name="l00289"></a><span class="lineno">  289</span><span class="comment"> * `boost::filesystem` is rock-solid and the model/original impl; which is not to say that always is enough</span></div>
<div class="line"><a id="l00290" name="l00290"></a><span class="lineno">  290</span><span class="comment"> * to take it over the `std::` counterpart.  However, some experiences with gcc-7&#39;s `std::filesystem` were</span></div>
<div class="line"><a id="l00291" name="l00291"></a><span class="lineno">  291</span><span class="comment"> * negative; it did not exist, and `std::experimental::filesystem` lacked basic chunks from the standard.</span></div>
<div class="line"><a id="l00292" name="l00292"></a><span class="lineno">  292</span><span class="comment"> * This left a bad taste in the mouth; whereas in the author&#39;s (ygoldfel) experience Boost&#39;s has been great.</span></div>
<div class="line"><a id="l00293" name="l00293"></a><span class="lineno">  293</span><span class="comment"> * It is very mature.</span></div>
<div class="line"><a id="l00294" name="l00294"></a><span class="lineno">  294</span><span class="comment"> */</span></div>
<div class="line"><a id="l00295" name="l00295"></a><span class="lineno">  295</span><span class="keyword">namespace </span>fs = boost::filesystem;</div>
<div class="line"><a id="l00296" name="l00296"></a><span class="lineno">  296</span><span class="comment"></span> </div>
<div class="line"><a id="l00297" name="l00297"></a><span class="lineno">  297</span><span class="comment">/// Short-hand for `flow::Error_code` which is very common.</span></div>
<div class="line"><a id="l00298" name="l00298"></a><span class="lineno"><a class="line" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">  298</a></span><span class="comment"></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a> = <a class="code hl_typedef" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">flow::Error_code</a>;</div>
<div class="line"><a id="l00299" name="l00299"></a><span class="lineno">  299</span><span class="comment"></span> </div>
<div class="line"><a id="l00300" name="l00300"></a><span class="lineno">  300</span><span class="comment">/// Short-hand for polymorphic functor holder which is very common.  This is essentially `std::function`.</span></div>
<div class="line"><a id="l00301" name="l00301"></a><span class="lineno">  301</span><span class="comment"></span><span class="keyword">template</span>&lt;<span class="keyword">typename</span> Signature&gt;</div>
<div class="line"><a id="l00302" name="l00302"></a><span class="lineno"><a class="line" href="namespaceipc.html#aa455c7f045059736578ca275fc1a851f">  302</a></span><span class="keyword">using </span><a class="code hl_typedef" href="namespaceipc.html#aa455c7f045059736578ca275fc1a851f">Function</a> = flow::Function&lt;Signature&gt;;</div>
<div class="line"><a id="l00303" name="l00303"></a><span class="lineno">  303</span> </div>
<div class="line"><a id="l00304" name="l00304"></a><span class="lineno">  304</span><span class="preprocessor">#ifdef IPC_DOXYGEN_ONLY </span><span class="comment">// Actual compilation will ignore the below; but Doxygen will scan it and generate docs.</span></div>
<div class="line"><a id="l00305" name="l00305"></a><span class="lineno">  305</span><span class="comment"></span> </div>
<div class="line"><a id="l00306" name="l00306"></a><span class="lineno">  306</span><span class="comment">/**</span></div>
<div class="line"><a id="l00307" name="l00307"></a><span class="lineno">  307</span><span class="comment"> * The `flow::log::Component` payload enumeration containing various log components used by Flow-IPC internal logging.</span></div>
<div class="line"><a id="l00308" name="l00308"></a><span class="lineno">  308</span><span class="comment"> * Internal Flow-IPC code specifies members thereof when indicating the log component for each particular piece of</span></div>
<div class="line"><a id="l00309" name="l00309"></a><span class="lineno">  309</span><span class="comment"> * logging code.  Flow-IPC user specifies it, albeit very rarely, when configuring their program&#39;s logging</span></div>
<div class="line"><a id="l00310" name="l00310"></a><span class="lineno">  310</span><span class="comment"> * such as via `flow::log::Config::init_component_to_union_idx_mapping()` and</span></div>
<div class="line"><a id="l00311" name="l00311"></a><span class="lineno">  311</span><span class="comment"> * `flow::log::Config::init_component_names()`.</span></div>
<div class="line"><a id="l00312" name="l00312"></a><span class="lineno">  312</span><span class="comment"> *</span></div>
<div class="line"><a id="l00313" name="l00313"></a><span class="lineno">  313</span><span class="comment"> * If you are reading this in Doxygen-generated output (likely a web page), be aware that the individual</span></div>
<div class="line"><a id="l00314" name="l00314"></a><span class="lineno">  314</span><span class="comment"> * `enum` values are not documented right here, because `flow::log` auto-generates those via certain macro</span></div>
<div class="line"><a id="l00315" name="l00315"></a><span class="lineno">  315</span><span class="comment"> * magic, and Doxygen cannot understand what is happening.  However, you will find the same information</span></div>
<div class="line"><a id="l00316" name="l00316"></a><span class="lineno">  316</span><span class="comment"> * directly in the source file `log_component_enum_declare.macros.hpp` (if the latter is clickable, click to see</span></div>
<div class="line"><a id="l00317" name="l00317"></a><span class="lineno">  317</span><span class="comment"> * the source).</span></div>
<div class="line"><a id="l00318" name="l00318"></a><span class="lineno">  318</span><span class="comment"> *</span></div>
<div class="line"><a id="l00319" name="l00319"></a><span class="lineno">  319</span><span class="comment"> * ### Details regarding overall log system init in user program ###</span></div>
<div class="line"><a id="l00320" name="l00320"></a><span class="lineno">  320</span><span class="comment"> * See comment in similar place in `flow/common.hpp`.</span></div>
<div class="line"><a id="l00321" name="l00321"></a><span class="lineno">  321</span><span class="comment"> */</span></div>
<div class="line"><a id="l00322" name="l00322"></a><span class="lineno"><a class="line" href="namespaceipc.html#a4ccdeed058222c635745a4dc830e99f7">  322</a></span><span class="keyword">enum class</span> <a class="code hl_enumeration" href="namespaceipc.html#a4ccdeed058222c635745a4dc830e99f7">Log_component</a></div>
<div class="line"><a id="l00323" name="l00323"></a><span class="lineno">  323</span>{<span class="comment"></span></div>
<div class="line"><a id="l00324" name="l00324"></a><span class="lineno">  324</span><span class="comment">  /**</span></div>
<div class="line"><a id="l00325" name="l00325"></a><span class="lineno">  325</span><span class="comment">   * CAUTION -- see ipc::Log_component doc header for directions to find actual members of this</span></div>
<div class="line"><a id="l00326" name="l00326"></a><span class="lineno">  326</span><span class="comment">   * `enum class`.  This entry is a placeholder for Doxygen purposes only, because of the macro magic involved</span></div>
<div class="line"><a id="l00327" name="l00327"></a><span class="lineno">  327</span><span class="comment">   * in generating the actual `enum class`.</span></div>
<div class="line"><a id="l00328" name="l00328"></a><span class="lineno">  328</span><span class="comment">   */</span></div>
<div class="line"><a id="l00329" name="l00329"></a><span class="lineno">  329</span>  <a class="code hl_enumvalue" href="namespaceipc.html#a4ccdeed058222c635745a4dc830e99f7a6fba12db09e5bebfaa04f6372c41c2cf">S_END_SENTINEL</a></div>
<div class="line"><a id="l00330" name="l00330"></a><span class="lineno">  330</span>};</div>
<div class="line"><a id="l00331" name="l00331"></a><span class="lineno">  331</span> </div>
<div class="line"><a id="l00332" name="l00332"></a><span class="lineno">  332</span><span class="comment">// Constants.</span></div>
<div class="line"><a id="l00333" name="l00333"></a><span class="lineno">  333</span><span class="comment"></span> </div>
<div class="line"><a id="l00334" name="l00334"></a><span class="lineno">  334</span><span class="comment">/**</span></div>
<div class="line"><a id="l00335" name="l00335"></a><span class="lineno">  335</span><span class="comment"> * The map generated by `flow::log` macro magic that maps each enumerated value in ipc::Log_component to its</span></div>
<div class="line"><a id="l00336" name="l00336"></a><span class="lineno">  336</span><span class="comment"> * string representation as used in log output and verbosity config.  Flow-IPC user specifies, albeit very rarely,</span></div>
<div class="line"><a id="l00337" name="l00337"></a><span class="lineno">  337</span><span class="comment"> * when configuring their program&#39;s logging via `flow::log::Config::init_component_names()`.</span></div>
<div class="line"><a id="l00338" name="l00338"></a><span class="lineno">  338</span><span class="comment"> *</span></div>
<div class="line"><a id="l00339" name="l00339"></a><span class="lineno">  339</span><span class="comment"> * As an Flow-IPC user, you can informally assume that if the component `enum` member is called `S_SOME_NAME`, then</span></div>
<div class="line"><a id="l00340" name="l00340"></a><span class="lineno">  340</span><span class="comment"> * its string counterpart in this map will be auto-computed to be `&quot;SOME_NAME&quot;` (optionally prepended with a</span></div>
<div class="line"><a id="l00341" name="l00341"></a><span class="lineno">  341</span><span class="comment"> * prefix as supplied to `flow::log::Config::init_component_names()`).  This is achieved via `flow::log` macro magic.</span></div>
<div class="line"><a id="l00342" name="l00342"></a><span class="lineno">  342</span><span class="comment"> *</span></div>
<div class="line"><a id="l00343" name="l00343"></a><span class="lineno">  343</span><span class="comment"> * @see ipc::Log_component first.</span></div>
<div class="line"><a id="l00344" name="l00344"></a><span class="lineno">  344</span><span class="comment"> */</span></div>
<div class="line"><a id="l00345" name="l00345"></a><span class="lineno">  345</span><span class="keyword">extern</span> <span class="keyword">const</span> boost::unordered_multimap&lt;Log_component, std::string&gt; <a class="code hl_variable" href="namespaceipc.html#a94386c9b549c1ea6be7e65e55c802d54">S_IPC_LOG_COMPONENT_NAME_MAP</a>;</div>
<div class="line"><a id="l00346" name="l00346"></a><span class="lineno">  346</span> </div>
<div class="line"><a id="l00347" name="l00347"></a><span class="lineno">  347</span><span class="preprocessor">#endif </span><span class="comment">// IPC_DOXYGEN_ONLY</span></div>
<div class="line"><a id="l00348" name="l00348"></a><span class="lineno">  348</span> </div>
<div class="line"><a id="l00349" name="l00349"></a><span class="lineno">  349</span>} <span class="comment">// namespace ipc</span></div>
<div class="ttc" id="adetail_2common_8hpp_html"><div class="ttname"><a href="detail_2common_8hpp.html">common.hpp</a></div></div>
<div class="ttc" id="anamespaceipc_html"><div class="ttname"><a href="namespaceipc.html">ipc</a></div><div class="ttdoc">Catch-all namespace for the Flow-IPC project: A library/API in modern C++17 providing high-performanc...</div><div class="ttdef"><b>Definition:</b> <a href="common_8cpp_source.html#l00021">common.cpp:22</a></div></div>
<div class="ttc" id="anamespaceipc_html_a4ccdeed058222c635745a4dc830e99f7"><div class="ttname"><a href="namespaceipc.html#a4ccdeed058222c635745a4dc830e99f7">ipc::Log_component</a></div><div class="ttdeci">Log_component</div><div class="ttdoc">The flow::log::Component payload enumeration containing various log components used by Flow-IPC inter...</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00322">common.hpp:323</a></div></div>
<div class="ttc" id="anamespaceipc_html_a4ccdeed058222c635745a4dc830e99f7a6fba12db09e5bebfaa04f6372c41c2cf"><div class="ttname"><a href="namespaceipc.html#a4ccdeed058222c635745a4dc830e99f7a6fba12db09e5bebfaa04f6372c41c2cf">ipc::Log_component::S_END_SENTINEL</a></div><div class="ttdeci">@ S_END_SENTINEL</div><div class="ttdoc">CAUTION – see ipc::Log_component doc header for directions to find actual members of this enum class.</div></div>
<div class="ttc" id="anamespaceipc_html_a94386c9b549c1ea6be7e65e55c802d54"><div class="ttname"><a href="namespaceipc.html#a94386c9b549c1ea6be7e65e55c802d54">ipc::S_IPC_LOG_COMPONENT_NAME_MAP</a></div><div class="ttdeci">const boost::unordered_multimap&lt; Log_component, std::string &gt; S_IPC_LOG_COMPONENT_NAME_MAP</div><div class="ttdoc">The map generated by flow::log macro magic that maps each enumerated value in ipc::Log_component to i...</div></div>
<div class="ttc" id="anamespaceipc_html_aa3192e586cc45d3e7c22463bf2760f89"><div class="ttname"><a href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">ipc::Error_code</a></div><div class="ttdeci">flow::Error_code Error_code</div><div class="ttdoc">Short-hand for flow::Error_code which is very common.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00298">common.hpp:298</a></div></div>
<div class="ttc" id="anamespaceipc_html_aa455c7f045059736578ca275fc1a851f"><div class="ttname"><a href="namespaceipc.html#aa455c7f045059736578ca275fc1a851f">ipc::Function</a></div><div class="ttdeci">flow::Function&lt; Signature &gt; Function</div><div class="ttdoc">Short-hand for polymorphic functor holder which is very common. This is essentially std::function.</div><div class="ttdef"><b>Definition:</b> <a href="common_8hpp_source.html#l00302">common.hpp:302</a></div></div>
</div><!-- fragment --></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Thu May 2 2024 23:56:38 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
